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(54) Semaphore for a computer system 

(57) A computer system Is descrbed In which 
access to a shared resource is controlled by a sema- 
phore. The semaphore comprises a lock value and a 
key value. When a process wishes to access the squired 
resource, it calls a reserve function which increments 
the lock value and stores the unchanged value of the 
lock value in a k)cal variable. The reserve function then 
performs a loop in which H repeatedly compares the key 
value with the local variable until they equal. When the 
pH-ocess has finished with the shared resource, it calls a 
release function which increments the key value. This 
guarantees to allocate the semaphore to processes in 
the order In which the processes requested It (I s. in 
chronological order), in a cheap and effective manner. 
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Description 

Background to the Invention 

[0001 ] This i nventlon relates to semaphores for com- s 
puter systems. 

[0002] A semaphore is a mechanism for corttrolling 
access to a shared resource by a number of concurrent 
processes. The shared resource may, for example, be 
an area of shared memory. TTie concun-ent processes 10 
may run on a single processor, or on cfifferent proces- 
sors. 

[0003] I n one known form of semaphore, referred to as 
a spinlock semaphore, each shared resource has a 
semaphore bit associated with it. Whenever a process 75 
wishes to access a shared resource, h tests the sema- 
phore bit associated with the resource. If the sema- 
phore bit Is set. the process '^spins" in a tight loop, in 
which it repeatedly tests the semaphore valua When 
the process finds thai the semaphore bit is reset, tt sets 20 
the semaphore bit and proceeds to access the shared 
resource. The testing and setting of the semaphore bit 
must be performed as a single atomic (i.e. indivisible) 
operation. When the process has finished accessing the 
shared resource, it resets the semaphore bit. 25 
[0004] A problem with this conventional spinlock sem- 
aphore, however, is that it cannot guarantee to allocate 
the semaphore to the processes in the order in which 
the processes requested it In particular, it is possible for 
two processes to continually swap a r^ouroe between so 
them, thereby btocWng a third process. The object of the 
present invention is to provide an improved spinlock 
semaphore that is guaranteed to allocate the sema- 
phore in the order in which the processes requested it. 

^mmarv of the Invertttan 

[0005] Accordi ng to the invention, a method of control- 
ling access by a plurality of processes to a plurafity of 
shared resources in a computer system oonrprises: 40 

(a) providing each of the shared resources with a 
first semaphore value and a second semaphore 
value: 

(b) when a process requires to access a shared 46 
resource, storing a reservation number as a local 
variable for the process* the reservation number 
being derived from the first semaphore val ue of the 
resource, updating the first semaphore value of the 
resource in a predetermined nmnner, performing a so 
loop which repeatedly compares the reservation 
number stored for the process with the second 
semaphore value off the resource, and permttting 

the process to access the resource when the reser- 
vation numt>er stored lor the process is in a prede- ss 
termined relationship with the secorxl semaphore 
value ol the resource; arxJ 

(c) when a process has finished accessing a shared 
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resource, updating the second semaphore value of 
the resource in a predetermined manner. 

Brief Descriptk^n of the Dravrings 

[0006] 

Figure 1 is a schematic diagram showing a compu- 
ter system embodying the invention. 

Figure 2 is a flow chart showing part of a client 
process. 

Figure 3 is a flow chart of a Reserve_semaphore 
function. 

Figure 4 is a flow chart of a Release_semaphore 
function. 

Descriptton of an Errtxadiment of the Invention 

[0007] One semaphore mechanism in accordance 
with the inventk)n will now t>e descrbed by way of exam- 
ple with reference to the accompanying drawings. 
[0008] Figure 1 shows a computer system 10. which 
runs a number of client processes 1 1 . The system may 
comprise a single processing unit with a nrulti-threading 
operating system altowing a number of processes to run 
concurrent^. Alternatively, the system may be a multi- 
processor system, in which cfifferent processes can mn 
simultaneously on different processors. 
[0O09] The dient processes 1 1 share a number of 
resources 12. such as memory. Each resource has a 
semaphore 13 associated with it. The semaphore com- 
prises a lock value 14 and a key value 15. The lock and 
key values are shared variables, and in this embodiment 
are initially set to the same value. 
[0010] Two functior^ are provided for managing the 
semaphores: a Reserve.semaphoreO functicn 16 and 
a Relea5e_semaphoreO function 17. These functions 
can be called by the client processes. 
[PO1 1 ] Figure 2 shows part of one of the client proc- 
esses whk:h makes use of the semaphore. 
[0012] (Step 21) When the client process wishes to 
access a shared resource^ it calls the 
Reserve^semaphoreO function. The call contains a 
parameter, specifying the identity of the semaphore 
associated with the resource In question. 
[0013] (Step 22) When this call returns, the client 
process accesses the shared resource. 
[0014] (Step 23} The client process then calls the 
Release_semaphorcO function. 
[0O15] Figure 3 shows the ReservajsemaphoreQ 
function. 

[0016] (Step 31) The function increments the lock 
value of the semaphore, and sets a local variable 
origLiock equal to the unincremerted value of the lock. 
This must be done as a single indivisfele action. For 



2 



PAGE 7/11 * RCVD AT 8/22/2006 3:56:08 PM [Eastern Daylight Time] " 8VR:USPTO-EFXRF-3/15 * DNIS:27383aO * C8ID:861 460-1986 * DURATION (mm-ss): 03-50 



8/22/2006 1:56 PM FROM: 661-460-1986 Huffman Patent Gcoup, LLC TO: 1-571-273-8300 PAGE: 008 OF Oil 



3 EP0953903A2 4 



exampla this step may be performed by the following 
Intel code: 

mov eax,1 

xadd lock.eax ; this is the Indrvisible action s 
mov origJock,eax 

[OCIT] it should be noted that there is a separate 
origL.lock per client, wtiereas all clients share the same 
lock and key values. 10 
[0018] (Step 32) The function then compares the key 
value of semaphore with the origjock value. If they are 
equal, the function returns; othenA/ise it repeats Step 32. 
Thus, the function performs a loop In which it repeatedly 
tests the key value of the semaphore, until the key value 75 
becomes equal to the origjock value. 
[0019] Figure 4 shows the Release_semaphoreO 
function. 

[0020] (Step 41) The function Increments the key 
value associated with the semaphore, and then returns. 20 
(Instead of incrementing the key, this step may set key = 
orig_lock + 1 , which in this embodiment gives the same 
result). 

[0021 ] It is not strictly necessary for the incrementing 
of the key value to be performed as an indivisible action, 25 
since the only client allowed to update the key value is 
the one currently holding the semaphore. 
[0022] In summary, it can be seen that the system pro- 
vides a spin lock semaphore having two components: a 
lock value and a key value. When a process reserves a so 
semaphore, the lock value is incremented and its unin- 
cremented value is saved as a local variable origLlock. 
If OrigLlock is equal to the key value, the process can 
immediate access the shared resouroe. if on the other 
hand orig_lock is not equal to the key value (because ss 
one or more processes have previously reserved the 
semaphore, and have not yet released it), a spin loop is 
entered. Eventually, the previous processes wffl release 
the semaphore, by incrementing the key valua When 
the key value becomes equal to origLk>cK the process 40 
is allowed to proceed to access the shared resource. 
[0023] In other words, when a process wishes to 
access a particu^ resource, it is allocated a reserva- 
tion number (origLlock), derived from the lock value of 
the resource. The process then waits until the key value 45 
of the resource is in a predetermined relationship with 
(in this embodiment is equal to) the reservation number 
of the process, before accessing the resource. 
[0024] The semaphore guarantees to allocate the 
semaphore to processes in the ord«^ in which the proc- so 
esses requested it {I.e. in chronologteal order). It is also 
very cheap (in terms of processing time and memory 
requlrennerTts) and effective. 

[0026] It will be appreciated that the lock and key val- 
ues will eventually reach a maximum value, and will roll- ss 
over to zero. 

[0026] This maximum value must be chosen to be 
greater than the maximum number of 



Reserve jsemaphore requests that may be pending at 
any given time. 

Some possible modHications 

[0027] It will be appreciated that many modifications 
may be rnexie to the system descrit>ed above without 
departing from the scope of the present invention. 
[0028] Different functions may be used to update the 
lock and key. For example, instead of incrementing the 
lock and key. they may be deaemented or rotated. 
[0029] Furthermore, instead of initialising the lock and 
key to the same value, they may inftlally have different 
values. In this case, instead of comparing the orig_lock 
and key for equality, the comparison checks whether the 
difference between origLlock and key is the same as the 
difference between the lock and key at start of day. 

Claims 

1. A method of controlling access by a plurality of 
processes to a plurality of shared resources in a 
computer system, the method comprising: 

(a) providing each of the shared resources with 
a first semaphore value and a second sema- 
phore value: 

(b) when a process requires to access a shared 
resource, storing a reservation number as a 
local variable for the process, the reservation 
number being derived from the first semaphore 
value of the resource, updating the first sema- 
phore value of the resource in a predetermined 
manner, perlorming a loop which repeatedly 
compares the reservation rujmber stored for 
the process with the second semaphore value 
of the resource, and permitting the process to 
access the resource when the reservaton 
number stored for the process is in a predeter- 
mined relationship with the second semaphore 
value of the resource: 

and 

(c) when a process has finished accessing a 
shared resource, updating the second senna- 
phore value of the resource in a predetermined 
manner. 

2. A method according to Claim 1 wherein ipdating 
the first semaphore value and storing the reserva- 
tk)n number as a local variable are poibrmed as a 
single indivisible action. 

3. A method according to Claim 1 or 2, wherein updat- 
ing the first semaphore value comprises increment- 
ing the first semaphore value, and updating the 
second sennaphore value comprises incrementing 
the second semaphore value 
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4. A method according 1o any preceding claim 
wherein the first and second semaphore key values 
are tnitialty set equal, and wherein the loop repeat- 
edly compares the reservation number with the 
second semaphore value until they are equal. 5 

5. A oonrputer system comprisi ng : 

(a) a plurality of processes; 

(b) a plurality of shared resources, each having 
a first semaphore value and a second sema- 
phore value; 

(c) a reserve function, callable by a process 
when the process requires to access a shared 
resource, the reserve function comprising 
means for storing a reservation number as a 
local variable for the process, the reservation 
number being derived from the first semaphore 
value of the resource, means for updating the 
first semaphore value of the resource in a pre- 
determined manner, means for performing a 
loop which repeatedly compares the reserva- 
tion number stored for the process with the 
second semaphore value of the resource, and 
means for permitting the process to access the 
resource when the reservation number stored 
for the process is in a predetermined relation- 
ship with the second semaphore value of the 
resource; 
and 

(d) a release function callable by a process 
when the process has finished accessing a 
shared resource, the release function compris- 
ing means for updating the second semaphore 
value of the resource in a predetermined man- 
ner. 

6. A computer system accorcfing to Claim 5 compris- 
ing means for updating the first semaphore value 
and storing the reservation number as a local varia- 40 
blei as a single indivisible action. 

7. A computer system according to Ctaim 5 or 6, 
wherein the means for updating the first semaphore 
value comprises means for incrementing the first 46 
semaphore value, and the means for updating the 
second semaphore value comprises means for 
incrementing the second semaphore value 

0. A computer system according to any one of Claims so 
5 to 7 wherein the first and second semaphore key 
values are initially set equal, and wherein the 
means for performing a loop repeatedly compares 
the reservation number with the second semaphore 
value until they are equal. ss 
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